home *** CD-ROM | disk | FTP | other *** search
/ The Original Shareware 1.1 / The Original Shareware (WeMake CDs)(Volume 1.1)(CDs, Inc)(1993).iso / 19 / madtrb40.zip / MSTREES.DOC < prev    next >
Text File  |  1986-05-05  |  13KB  |  310 lines

  1. Implementation of a Generalized
  2. Median Split Tree
  3.  
  4. by Chris Maeder
  5. CS 577
  6.  
  7.  
  8.  
  9.  
  10. Introduction
  11.  
  12. An important task in many computer applications today is the
  13. retrieval of information associated with an identifier (or "key")
  14. from a table of identifier-information pairs.  Usually these
  15. applications involve sets of keys whose frequency occurrence have a
  16. highly skewed distribution, sometimes so skewed that only a small
  17. fraction of the keys are used in most of the information retrievals.
  18.  
  19. Typical applications in which such key-information pairs arise
  20. include dictionary word look-up, thesaurus word look-up, and spelling
  21. checking in text processing applications (Sheil [1] cites that in the
  22. English language, for example, 127 of the most frequent words account
  23. for approximately 50 percent of an average text), telephone directory
  24. information, the recognition of operating system commands, and the
  25. compiler's symbol look-up table (where language keywords and other
  26. commonly used variables names will appear more frequently than other
  27. words).
  28.  
  29. Most look-up techniques ignore the frequencies of these
  30. key-information pairs, thereby tending to scatter the more frequently
  31. occurring keys uniformly throughout the look-up table.  This usually
  32. results in an unacceptably high rate of external memory references,
  33. especially if such table is quite large.  Thus it should be apparent
  34. that it is preferable to separate out the more frequently occurring
  35. keys into a separate look-up table that can be quickly searched
  36. without external memory references. 
  37.  
  38. We present here an implementation of a median split tree that was
  39. first presented in Communications of the ACM [2], November, 1978,
  40. that optimizes the look-up of frequently occurring keys.
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Generalized Median Split Trees
  56.  
  57. Median split tree (MST) algorithm provides us with a means for
  58. searching sets of identifiers that have highly skewed frequency
  59. distributions.  
  60.  
  61. An MST is essentially a binary search tree with two key entries per
  62. node--a node key entry and a split key entry.  The node key entry is
  63. the most frequently accessed key in the subtree.  The split key entry
  64. partitions the remaining keys in the subtree into two equal subsets,
  65. each of which are organized as an MST.  The MST uses this lexical
  66. median of a node's descendants as its split value in order to force
  67. the search tree to be balanced, thereby achieving both a space
  68. efficient representation of the tree and high search speed.
  69.  
  70. A query of the MST begins at the root of the MST, then following the
  71. tree's nodes in a binary search fashion, first comparing the most
  72. frequent key and then the split key to determine which subtree to
  73. proceed downward with.  The MST frequently encounters the proper keys
  74. early in a query, and therefore has a lower cost per successful
  75. search than a typical balanced binary search.
  76.  
  77. We can further generalize the above algorithm, as presented in ACM
  78. Transactions on Programming Languages and Systems [3], January, 1980,
  79. to allow each node to handle more than two key entries per node.  A
  80. query into the MST then examines each entry in a node sequentially,
  81. stopping once the proper key has been found.  If a match has not
  82. occurred after comparing the key entries in a node, the query then
  83. proceeds down the left or right subtree depending upon the comparison
  84. with the last key in the node.  This last key in the node acts as the
  85. median split key, partitioning the remaining look-up keys in the
  86. subtree into equal left and right subtrees.
  87.  
  88. We can thereby define an m-median split tree to be an MST with m
  89. entries per node (where m>2).  Observe that the root of each subtree
  90. in an m-MST contains the m-1 most frequently accessed keys for that
  91. particular subtree, and the median split key which partitions the
  92. remainder of the look-up keys in the subtree.  
  93.  
  94. One should note that when m=1 we have essentially a balanced binary
  95. search tree, when m=2 we have a conventional median split tree, and
  96. when m=n we have essentially a sequential search.
  97.  
  98. Average and worse case complexity for the construction and query
  99. algorithms for m-MST can be found in the referenced material.
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Construction of Median Split Trees
  110.  
  111. We have developed two construction algorithms for the construction of
  112. the m-MST, but note that only the first construction algorithm was
  113. fully implemented.  Both construction algorithms assume that the
  114. stored set of keys have been previously sorted according to their
  115. lexical value.
  116.  
  117. In both construction algorithms, the file containing the look-up keys
  118. is read and the keys are placed into a doubly linked list,
  119. maintaining the keys in their sorted lexical order.
  120.  
  121. The first m-MST construction algorithm builds the m-MST using only
  122. the lexical ordering of the given set of keys.  The construction
  123. algorithm is applied recursively as it builds the tree, continually
  124. splitting the doubly linked list in half at the median split key
  125. linked list element.
  126.  
  127. Each m-MST subtree's root node is filled with the m-1 most frequently
  128. occurring keys in that particular subtree.  Note that the elements
  129. that belong to that particular subtree are the elements that remain
  130. on the passed linked list.  The most frequent elements are selected
  131. and deleted from the linked list using a sequential search.
  132.  
  133. Next, the median split key is selected from the remaining keys in the
  134. linked list.  The split key selection is such that it fills the
  135. current m-MST subtree's child nodes as completely as is possible. 
  136. This split key splits (or partitions) the remaining keys into the
  137. node's left and right subtrees, hence the linked list is broken in
  138. half at this split key.
  139.  
  140. As previously stated, the process described above is applied
  141. recursively until the entire m-MST is built.
  142.  
  143. To somewhat optimize the above construction algorithm it was decided
  144. to construct the m-MST using both orderings of the given set of keys.
  145.  Again, one of the orderings is the actual lexical ordering of the
  146. keys as is supplied in the file of look-up keys.  These keys were
  147. then ordered according to their frequency of occurrence using a
  148. quicksort on a duplicated linked list, placing the entries into a
  149. priority queue.
  150.  
  151. The priority queue is then used to determine the most frequently
  152. occurring keys in the current subtree.  Note that we could have also
  153. have implemented a heap instead of a priority queue.
  154.  
  155. The linked list of look-up keys and the priority queue keys are
  156. linked together using a double pointers.  This was done so that when
  157. the next most frequent key was removed from the priority queue, it is
  158. possible to immediately delete that same key from the doubly linked
  159. list.
  160.  
  161. Problems occurred with this second m-MST construction algorithm when
  162. attempting to devise a means of splitting the doubly linked list at
  163. the split key.  Observe that the pointers into the priority queue
  164. from the linked list are very intermixed.  We did not come up with a
  165. clean, straight forward method of splitting the priority queue about
  166. the split key element.  We therefore stopped with this second
  167. construction implementation after it was discovered that the linked
  168. list and priority queue splitting technique was not going to add much
  169. to the construction speed of the m-MST due to its inherit complexity.
  170.  
  171. To optimize the look-up algorithm it was decided that the node data
  172. record structure should be that of an array of size
  173. [1..MAX_KEYS_PER_NODE] not including the split key.  The split key is
  174. separate element in the node's data structure.  With this node data
  175. structure we were then able to sort the node's array of look-up keys
  176. based upon their lexical value.  
  177.  
  178. By sorting the keys in the node array according to their lexical
  179. value allowed us to include in the search algorithm a binary search
  180. for searching within each node, rather than the sequential search as
  181. was proposed in [].  Using the binary search within each node
  182. effectively increases the look-up speed of keys, especially when
  183. implemented with large node key arrays.  Observe that a interpolation
  184. search could be implemented in place of the binary search if so
  185. desired, but that more expensive numeric calculations are involved.
  186.  
  187. We report that it only took a couple of seconds to construct a m-MST
  188. with 256 keys on a IBM micro computer using the first construction
  189. algorithm.  Since we believe that there will not much improvement in
  190. speed with the second construction algorithm, in actual practice it's
  191. probably better to implement only the first (and far more simpler)
  192. construction algorithm.  Also note that the m-MST need only be built
  193. once, then being stored in some form externally when not needed.  
  194.  
  195. We included in our implementation a display representation of the
  196. m-MST once it has been constructed.  This display demonstrates how
  197. the more frequent keys are positioned further up in the tree, and how
  198. the split keys partition the left and right subtrees.
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217. Selection of Median Split Keys
  218.  
  219. Median split trees use a node's split key value as the median for
  220. partitioning (with respect to the lexical ordering) the remaining
  221. nodes into the left and right subtrees.  The choice of split value is
  222. very important since it can result in a perfectly balanced tree,
  223. thereby allowing optimal information yield for each node comparison.
  224.  
  225. Observe that it would be preferable to have each node filled to its
  226. capacity in order to keep the tree as completely full as is possible.
  227.  Therefore it was necessary to develop a split key function that
  228. provided a lexical order index that allowed us to select a key
  229. closest to the actual median of the keys, and yet completely fill as
  230. many of the subsequent m-MST nodes as is possible.
  231.  
  232. The median split key function originally proposed in [2] was altered
  233. to take in account the modification in the search algorithm we have
  234. implemented.  The following function is used in order to determine a
  235. split key that gives the key closest to the median (based upon the
  236. lexical ordering of the remaining keys), and yet fills the child
  237. nodes completely.
  238.  
  239.   SplitValue=((MAX_KEYS_PER_NODE+1)*IntegerMultiplier
  240.  
  241. where SplitValue is chosen to be closest to the actual median of the
  242. remaining keys and IntegerMultiplier is of the form 1,2,3,...
  243.  
  244. One should observe from our sample run that only one node is not
  245. completely full in the entire m-MST.  This is because of the way the
  246. above split key function splits the keys at the m-MST root node so
  247. that all remaining nodes, except possibly the right-most node, will
  248. be filled completely.
  249.  
  250.  
  251.  
  252.  
  253. Queries into the m-MST
  254.  
  255. Queries into the m-MST are very straight forward.  First the node
  256. array is scanned using a binary search.  As was stated previously,
  257. this binary search is an optimization on the given search algorithm. 
  258. If after the node array search a match has not been found, the split
  259. key is then checked to determine if it possibly matches the query. 
  260. Failing that test a determination is made which of the node's two
  261. subtrees the query should continue to search.
  262.  
  263. A look-up key comparison counter was included in the search
  264. implementation so that there could be some indication of the number
  265. of comparisons being performed for each m-MST query.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271. Further Enhancements Considered for the m-MST Algorithm
  272.  
  273. One possible method that was considered but not implemented was to
  274. map the m-MST keys into an array instead of storing the keys in a
  275. actual tree.  This type of storage technique has previously been
  276. implemented to store binary search tree representations of data in
  277. languages that do not support pointers, such as Fortran and Cobol. 
  278. Note that an already constructed m-MST can be very quickly read into
  279. an array.  
  280.  
  281. A problem that must be overcome in other array implementations of
  282. search trees is tree balance and completeness.  This is especially
  283. difficult when dealing with dynamic data where the tree is
  284. continually growing and shrinking.  An array implementation of a
  285. m-MST makes a great deal of sense since it is remains stable (i.e. is
  286. not dynamic), is complete, and is very well balanced.
  287.  
  288. To access a particular node in the array a node access function
  289. similar to what is used in binary search tree array implementation 
  290. could be used for the m-MST.
  291.  
  292.  
  293. References
  294.  
  295. 1. Sheil, B. A. Median Split Trees: A Fast Look-up Technique for
  296. Frequently Occurring Keys. Comm. ACM 21, 11 (Nov. 1978), 948.
  297.  
  298. 2. Sheil, B. A. Median Split Trees: A Fast Look-up Technique for
  299. Frequently Occurring Keys. Comm. ACM 21, 11 (Nov. 1978), 947-958.
  300.  
  301. 3. Comer, D. A Note on Median Split Trees. ACM Trans on Prog. Lang.
  302. and Sys. 2, 1 (Jan. 1980), 129-133.
  303.  
  304. 4. Comer, D. A Note on Median Split Trees. ACM Trans on Prog. Lang.
  305. and Sys. 2, 1 (Jan. 1980), 130.
  306.  
  307. 5. Sheil, B. A. Median Split Trees: A Fast Look-up Technique for
  308. Frequently Occurring Keys. Comm. ACM 21, 11 (Nov. 1978), 950.
  309.  
  310.